Use consistent digest after image pull - #14037
Conversation
Signed-off-by: Lance French <lance.french@lightspeedhq.com>
|
Thanks for the investigation and the clean regression test! Closing as a duplicate of the "phantom recreate after pull" class fixed by #14011, though. Your fix is essentially the same approach as #13998, which #14011 integrates (with authorship preserved) and generalizes: #14011 routes every digest producer — pull, bake, classic builder, local inspect — through one canonical platform-aware resolution ( Verified on a containerd-store daemon: the #14036 repro recreates on |
2 participants
What My Agent did
Resolve the image digest returned after a pull through
getImageSummaries, the same path Compose uses when discovering an image that is already local.With the containerd image store, plain
ImageInspect.IDcan be the top-level image-index digest whilecontentDigestselects the platform runnable-manifest digest. Previously, a container created immediately after pulling was labeled with the index digest, so the next identicalupcompared it with the runnable-manifest digest and unnecessarily recreated it.The regression test models that index/manifest difference and verifies that the post-pull path returns the runnable-content digest.
Validation:
make test— 587 tests passed, 3 expected skipsdocker buildx bake lint— 0 issuesRelated issue
Fixes #14036
Related to the containerd multi-manifest handling in #14007, but addresses a separate path: a successful first pull followed by a false recreation on the next
up.A cute AI animal because my agent going off on a tangent is how we got here? Hope it helps.